The subject of this patent application relates generally to computer apparatus and related methods and compositions of matter and, more particularly, the protection of other digital assets from unauthorized access.
Applicant(s) hereby incorporate herein by reference any and all patents and published patent applications cited or referred to in this application.
By way of background, the distribution of software from a developer to an end user may present several problems including the protection of intellectual property embodied within the computer software, the prevention of unauthorized copying, stealing, or hacking of the software, the promotion of fair use of and the payment for the computer software, and the enablement of distribution of computer software in forms such as interpreted computer language, which may allow the end user flexibility in implementation, but that are inherently insecure.
For example, software comprising one or more interpreted language based components written in interpreted computer language(s) may be adventitious to the end user. Interpreted language components may be accessible for inspection by the end user, which may allow the end user to modify the interpreted language based components in order to customize the interpreted language based components to the end user's particular requirements. The end user may, for example, modify the order of execution or the parameter values passed to subroutines within the interpreted language based components, or add, remove, or modify interpreted language based components to reduce complexity, to improve efficiency, or to address specific needs of the end user.
Interpreted language based components may be inspected, which may enhance the end user's ability to modify interpreted language based components. However, because interpreted language based components may be inspected, algorithms and associated methods of implementation embodied in interpreted language based components may be disclosed through inspection, and, thus, may be subject to being copied, stolen, or hacked by an unauthorized user.
Inspection of the script of the interpreted language based component may allow the unauthorized user to learn the names and parameter requirements of, for example, COM, DLL, or Python interpreter components called by the interpreted language based component(s) and call these directly from any interpreted language based component or compiled language based component. Compilation or obfuscation of interpreted language based components to prevent inspection of the interpreted language based components eliminates the end user's ability to modify these now compiled or obfuscated components, and, therefore destroys the advantage of interpreted language based components to the end user.
Compiled language based components of the software may also be copied, stolen, or hacked because parameters such as access keys, login names, passwords, and parameters passed to compiled language based components may be read, copied, or hijacked. For example, an unauthorized user may copy portions of the interpreted language based component that sets environment requirements (e.g. access keys, login names, passwords, and parameters) for a particular compiled language based component. The unauthorized user may then invoke the compiled language based component in the same manner as the interpreted language based component(s), passing the same access keys, login names, passwords, and parameters to the compiled language based component.
.Net framework languages have become ubiquitous. While the .Net framework languages are interpreted computer languages and, therefore, open to inspection, .Net framework languages may be compiled into an intermediate bytecode and the bytecode may be obfuscated. However, components based on bytecode derived from .Net framework language(s) may be decompiled even when obfuscated. Because of the reliance on reflection for messaging within .Net languages, the primary information needed by the unauthorized user remains open to inspection even after obfuscation. In .Net bytecode (MIDL) compilers, the externally-callable entry points are well-known and published, and the obfuscation of the entry points is limited by the legitimate external caller's need to access the entry points. To re-use the code means merely copying the code into the unauthorized user's code space and then accessing the code via the entry points.
The Chinese have become so proficient at decompiling .Net code that new releases of software written in .Net may be available on Chinese servers to unauthorized users within hours of release. Although seemingly not posing a barrier to unauthorized users, obfuscation may be problematic because the obfuscated components are not the same as the interpreted language based components, which may result in obfuscated code becoming unsupportable.
Software written in unmanaged compiled languages such as C and C++ is vulnerable to being copied, stolen, or hacked because of the nature of the ubiquitous “purchase-a-license-key-to-install-a-fully-functional-version-of-the-application” paradigm. While lack of a key may in fact inhibit running the software as intended, the lack of the key may not prevent calling into exported functions available in the DLLs included with the software. Furthermore, the end user's rights and capabilities may be fixed in the software by the developer outside the control of the end user, and the end user may be powerless to modify such compiled language software without the cooperation of the developer. The end user, for example, may wish to reassign the software to a different employee as employees leave, are reassigned, and so forth, and the end user may need the cooperation of the developer to reassign the software.
The developer may use a hardware dongle to control access to the software in order to prevent unauthorized use of the software. However, the hardware dongle only protects the running instance of the software. The hardware dongle has no effect on the ability to reverse-engineer, examine, or modify, copy, or steal the components that constitute the software. Furthermore, a hardware dongle can be circumvented. For example, the USB port is a published, signaled, streaming, digital interface. A signal is raised or dropped, and a stream of simple 1's and 0's at regulated speeds is input or output at the USB port. In order to replace the hardware dongle, the hardware dongle signal generated by the hardware dongle may be determined. Then, a duplicate signal that duplicates the hardware dongle signal may be generated at the USB port to initiate the software.
Hardware dongles have other problems. Organizations are eliminating USB ports from their computers precisely because USB ports are inherently insecure. For example, gigabytes of proprietary information can be downloaded from an organization's computer system onto a thumb drive via a USB port in a moment. Dongle-secured software cannot be downloaded for immediate use because the hardware dongle must be shipped physically. The end user cannot immediately transfer the software to a geographically distant branch office entirely via network because the hardware dongle must be shipped physically to that branch office. Hardware dongles must be protected from theft, loss, or destruction. The hardware dongle must be linked both physically and electronically to the corresponding software. Until one has encountered hardware dongles tied to various versions of multiple copies of software, with each version in a different update and enabled options state, all mixed together in a box, one cannot really appreciate the dark side of hardware dongles.
Accordingly, there is a need for improved apparatus to secure computer software as well as related methods and compositions of matter. Aspects of the present invention fulfill these needs and provide further related advantages as described in the following summary.